在當今天軟體開發中，自動化測試作為 DevOps 的其中一個環節，扮演著其中重要的角色，透過自動化測試，開發團隊可以更快速的迭代程式碼，及時發現並修正問題，從而縮短產品上市時間。此外，自動化測試還能執行大量的回歸測試，降低修 A 壞 B 的情況，這有助於提升產品的穩定性和可靠性，除了提高效率和穩定性，自動化測試還可以集成到持續集成和持續交付（CI/CD）流水線中，進一步加快開發和部署的速度。
自動化測試顧名思義是指透過工具來自動執行測試，模擬用戶或是測試人員的操作，驗證被測試對象的行為是否符合預期，通常提到這裡，測試金字塔就會跑出來了，然後肯定會提一下說 E2E、Unit Test 的比例應該要佔多少比較好，這些都是老生常談的議題了，撇開這些來說，最終的目的都是希望透過技術手段來確保品質及加速迭代。
隨著 DevOps 的蓬勃發展，自動化測試在 DevOps 中扮演了相當重要的角色，在過去透過手動測試的背景下，測試人員需要花費許多時間在測試上，不管事專案中的測試，或是上線前的回歸測試，都有種讓大家覺得時間都卡在測試的感覺，因此透過自動化測試開發人員可以在版本迭代時非常快速的取得測試成果，也是個老生常談的議題了，當今天越早發現版本中的錯誤時，修復問題的速度會越快、成本也越低。
當提到 UI 自動化測試時，經常會浮現兩派人馬，一派人提倡 UI 自動化測試的，另一派人則是質疑 UI 自動化測試的報酬率，質疑 UI 自動化測試的人傾向透過建立線上監控的機制和告警系統，增加感知能力做到盡早發現盡早修復，沒有說誰一定是對的，或誰一定是錯的，我們需要根據當前的情況在有限的資源下做出最有利組織及品質的選擇。
同時自動化測試案例的多寡，與品質之間的關係並非成正比的，雖然透過提高自動化測試的覆蓋率有機會測試到更多的缺陷，但是同時維護自動化測試的成本也是不小的，並且我們還需要定期審視自動化測試案例的有效性，用來充數量的測試案例會導致虛假的安全感，造成測試資源的浪費。
在這個系列中，我們不會提到過多關於軟體品質的概念，我們先預設大家對於測試，對於如何交付優秀的品質具備一定的了解，並且期待透過自動化測試來加入產品的迭代，因此本系列會將重點放在，如何打造應用程式的 UI 自動化測試，因此如果是對 UI 自動化測試有興趣的夥伴，走過路過千萬不要錯過啦！在未來 30 天，我們將分享到該如何透過 RobotFramework 撰寫應用程式的 UI 自動化測試，其中包含透過 RobotFramework 搭配 Playwright 撰寫 Web 自動化測試，以及透過 RobotFramework 搭配 Appium 撰寫 Android、iOS 自動化測試，希望透過這系列的文章可以讓大家在開發應用程式的 UI 自動畫測試時有個可以參考的脈絡，接著就讓我們一起開始這 30 天的挑戰吧！
我們將分享分成三大部分：
iThome鐵人賽
看影片追技術